Extended HTTP error channel

ABSTRACT

Techniques for clients and servers to use the web authoring extensions, and in particular, extended error handling to allow servers to provider richer web authoring error information to clients.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation and claims the benefit of U.S. patentapplication Ser. No. 11/217,626, filed Aug. 31, 2005, titled“COMPOUNDING OF HTTP AUTHORING PROTOCOL”, which is incorporated hereinby reference.

BACKGROUND

FIG. 1 shows an HTTP message 50. The exchange of HTTP messages 50between an HTTP client 52 and an HTTP server 54 is well known in the artof client-server computing. Various RFCs and other public documents maybe consulted for details about the various versions and variations ofHTTP. For instance, RFC 2616 defines HTTP version 1.1. According to RFC2616, an HTTP message 50 that is for an HTTP request has a request line54, such as “GET/HTTP/1.1”. An HTTP message 50 that is for an HTTPresponse instead has a status line 56, such as “HTTP/1.1 200 OK”. Arequest line 54 or status line 56 is usually followed by one or moreheaders, each consisting of a field name 60 and, depending on theparticular header, zero or more field bodies 62. A message 50 may endwith a message body 64, depending on the type of request or response.Details relating to delimiters, particular headers, and other featuresof HTTP messages and HTTP communication can be found elsewhere.

FIG. 2 shows an example HTTP request 80 and an example HTTP response 82.The HTTP client 52 sends request 80 over a data network 84 to the HTTPserver 54, which handles the request and returns the response 82. Therequest 80 includes a request line 87 and a number of headers 88 (somerequests also have a message body). The response 82 includes a statusline 89, headers 90, and a message body 92. HTTP communications need nottravel over a network such as network 84; communication between a localclient and a local server is possible, albeit usually through the localsystem's communications stacks.

A shortcoming with HTTP is that it does not provide for authoringthrough an HTTP channel. That is, the standard HTTP specifications donot specifically provide for clients to manage resources on servers.There is no way for a client to perform resource management operationslike copying resources (e.g., files, documents, etc.), moving resourceson a server, setting or obtaining properties of resources on a server,locking resources, and so on. In response to this shortcoming, variouspublic and private extensions to HTTP have been devised.

FIG. 3 shows some method extensions 100 and header extensions 102 of aprotocol or extension of HTTP that adds remote authoring functionalityon top of HTTP. These extensions are from RFC 2518, which defines “HTTPExtensions for Web Authoring and Versioning”, or “WebDAV”. WebDAV is asuperset of HTTP that is sometimes referred to as a protocol, andsometimes referred to as an extension of HTTP. The WebDAV protocoldefines conventions, methods 100, and headers 102, for requests andresponses that otherwise comply with HTTP. That is, WebDAV requests andresponses follow the basic format of HTTP messages (e.g., message 50 inFIG. 1). Technically, some of the verbs in the web authoring methods 100are defined as valid HTTP verbs, however, their functionality isextended by WebDAV. For example, PUT is part of HTTP, but WebDAV extendsits functionality to collections, directories, folders, etc. The samebasic HTTP communication rules are used, the same line/field/bodydelimiters are used, the same error codes may be used, and base HTTPmethods 104 and base HTTP headers can appear in WebDAV messages. Forexample an ordinary HTTP OPTIONS request may be answered by aWebDAV-compliant server with a response that has standard HTTP headersas well as one or more non-standard HTTP headers that indicate theavailability of one or more HTTP extensions on the server. In general,this manner of extending HTTP allows servers and clients to handle bothbase HTTP communications as well as various extensions thereto, even ifa remote system does not support an extension that is supported locally;unsupported headers and methods are usually ignored or handledgracefully.

The WebDAV extension to HTTP provides functionality to create, changeand move documents on a remote server (typically a web server). WebDAVimplementations are useful, among other things, for remotely authoringdocuments or resources served by a web server. WebDAV implementationscan also be used for general access-anywhere web-based file storage.Many operating systems, such as Windows, Linux, and Mac OSX providebuilt-in client and server support for WebDAV, thus allowing transparentuse of files on a WebDAV server somewhat as if they were stored in alocal directory.

The methods and headers of WebDAV are fully documented elsewhere,however, the main methods are: PUT—put a resource or collection on theserver; DELETE—delete a resource or collection from the server;PROPFIND—retrieve properties (as XML) of a resource; PROPPATCH—changeand delete properties of a resource; MKCOL—create collections ordirectories; COPY—copy a resource from one URI to another on the server;MOVE—move a resource from one URI to another on the server; LOCK—put alock on a resource; UNLOCK—remove a lock from a resource. Some notableheaders (field names) are: destination—specifies a URI as a destinationresource for methods such as COPY and MOVE; Lock-Token—specifies a tokenthat identifies a particular lock; and Timeout—specifies a duration of alock.

It has not previously been recognized that there are certaininefficiencies and weaknesses built into WebDAV that can becomesignificant in certain circumstances. FIG. 4 shows a timeline for asequence of related authoring requests. Suppose that a user of HTTPclient 52 would like to get and lock a resource on HTTP server 54. Theuser will first direct the client 52 to get a particular resource. Theclient 52 will generate and transmit a GET request 120 to the server 54.The server 54 handles the GET request 120 and returns an appropriateresponse 122. The round trip time is the time between client 52'stransmission of the GET request 120 and the receipt of response 122. Ascan be seen in FIG. 4, much of the round trip time can be attributed tothe time that it takes for the GET request 120 and the response 122 totraverse the network. If the user also needs to lock the resourceobtained by GET request 120, another round of communication is needed:client 52 sends discrete LOCK request 124; LOCK request 124 passesthrough the network; and the server 54 replies with a response 126 thatalso crosses the network. The second exchange has its own round triptime that may include significant network transmission time. The totaltime 128 to meet two related needs of the client 52 (the need to bothget and lock a resource) includes the time for two round trips or fournetwork transmissions. Furthermore, the two discrete requests 120, 124require approximately twice the server overhead as a single request,which might cause further delay if the server is heavily loaded.

Another problem with the example in FIG. 4 is that the requestedresource could be modified or locked by another client (or the server 54itself) between the time that client 52 requests the resource and thetime the client 52 is able to obtain a lock on the resource. In otherwords, another request can affect the resource after it is received bythe client 52 but before the client 52 is able to obtain a lock on theresource, which could cause an error or unexpected result.

The atomic nature of WebDAV and the inability of WebDAV clients andservers to use compound or multi-aspect authoring requests with onediscrete exchange may have other problems and inconveniences. Withoutnecessity, some embodiments discussed below may alleviate some problemsassociated with HTTP authoring.

SUMMARY

The following summary is included only to introduce some conceptsdiscussed in the Detailed Description below. This summary is notcomprehensive and is not intended to delineate the scope of protectablesubject matter, which is set forth by the claims presented at the end.

Certain client-server communication conventions extend compounded webauthoring methods to a web authoring protocol such as WebDAV. Moreparticularly, a web authoring request can be provided with specialheader information to signify a first web authoring method compoundedwith a second web authoring method indicated by a verb in the request.Clients and servers are provided with techniques to use the webauthoring extensions. Extended error handling can be used to allowservers to provider richer web authoring error information to clients.

Many of the attendant features will be more readily appreciated byreferring to the following detailed description considered in connectionwith the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

Like reference numerals are used to designate like parts in theaccompanying Drawings.

FIG. 1 shows an HTTP message.

FIG. 2 shows an example HTTP request and an example HTTP response.

FIG. 3 shows some method extensions and header extensions of a protocolor extension of HTTP that adds remote authoring functionality on top ofHTTP.

FIG. 4 shows a timeline for a sequence of related authoring requests.

FIG. 5 shows some web authoring method extensions and compounding headerextensions that can be used to allow clients and servers to compound twoor more authoring related methods with single client-server exchanges.

FIG. 6 shows an uncompounded authoring exchange and a compoundedauthoring exchange with a similar purpose.

FIG. 7 shows how a client can determine if compounding is available on aserver.

FIG. 8 shows how requests can be formatted to invoke compounded locking.

FIG. 9 shows a mechanism for compounding property methods with HTTP orWebDAV methods or verbs.

FIG. 10 shows further compounded methods.

FIG. 11 shows an example POST+PROPFIND+LOCK method request and acorresponding response.

FIG. 12 shows an error handling table and examples of a response usingextended error handling.

DETAILED DESCRIPTION

FIG. 5 shows some web authoring method extensions 140 and compoundingheader extensions 142 that can be used to allow clients and servers tocompound two or more authoring related methods with single client-serverexchanges. Although the method extensions 140 are characterized as“methods”, they need not involve verbs or request lines 54 that aredifferent than those defined by HTTP and WebDAV. However, conceptually,the method extensions 140 discussed below effectuate compound authoringmethods. As discussed below, these in-effect compound authoring methodextensions 140 can be accomplished using various compounded headerextensions 142.

In the Figures, the symbols “+” and “|” (vertical bar) respectivelyrepresent compounding and “or”. So, for example, the“POST|GET+LOCK|REFRESH|UNLOCK” method 144 represents a number ofdiscrete compound methods: “POST+LOCK”, “POST+UNLOCK”, “GET+LOCK”, etc.An explanation of how the method extensions 140 can be implemented usingheader extensions 142 will follow. Methods 144 and 146 will be discussedwith reference to FIG. 8. Methods 148 and 150 will be discussed withreference to FIG. 9. Methods 152 and 154 will be discussed withreference to FIGS. 10 and 11.

FIG. 6 shows an uncompounded authoring exchange and a compoundedauthoring exchange with a similar purpose. The left hand side of FIG.6—a repetition of FIG. 4—shows the flow of an uncompounded authoringexchange. The right hand side of FIG. 6 shows the flow of a compoundedauthoring exchange. On the right hand side of FIG. 6 (the compoundedexample), a single request message 170 is sent by the client 52. Therequest message 170 includes information indicating a GET operationdirected to a resource on server 174 and information indicating that theserver 174 is to also lock the resource for the client 172. In thecompounded case, there is one exchange with the time of one round trip.The total transaction time 174 for the compounded request 170 is lessthan the total transaction time 128 of the uncompounded requests 120,124. Furthermore, because the server 174 can tell from the requestmessage 170 that a lock is desired, the server 174 can immediately lockthe requested resource, thus preventing an intervening request frominterfering with client 172's request.

FIG. 7 shows how client 172 can determine if compounding is available onserver 174. As mentioned earlier, it is desirable (but not necessary)for a client to be able to use both compounded and uncompoundedauthoring requests. It is also desirable for a server to be able tosupport both compounded and uncompounded authoring requests. A mechanismcan be provided for this purpose. Preferably, the mechanism involvesincluding information in a server response that indicates whethercompounding is supported by the server. Although this information cantake any form, the use of a new response header 190 is convenientbecause clients usually ignore unrecognized headers in an HTTP response.Furthermore, known algorithms for header parsing can be readily extendedto process a new header or field name. In the alternative, a compoundingindicator can take the form of a new value for a standard header, aspecial status line, etc.

To establish the availability of compounding, the client 172 performs aprocess 192 that starts with sending a standard OPTIONS request 194(request 194 is only an example). A process 196 on the server 174receives the OPTIONS request 194 and generates a response such asresponse 198 that includes a compounding indicator, in this embodiment,non-standard response header 190. The actual name of the non-standardresponse header 190 is not important other than it be known in advanceby the client 172 so that when the client's 172 process 192 receives theresponse 198 it can recognize it and communicate with the server 174 asappropriate.

FIG. 8 shows how requests can be formatted to invoke compounded locking.The top part corresponds to the extended methods 144 (see FIG. 5) forGET or POST locking, and the lower part corresponds to the extendedmethods 146 for PUT locking. In one embodiment, ordinary HTTP and WebDAVrequest verbs 220 GET, POST, and PUT are compounded with lockingrequests using various combinations of a standard Lock-Token header 222and a non-standard or extended lock timeout header 224, for example“X-MSDAVEXTLock-Timeout”. The lock timeout header 224 has a value of 0or more seconds.

The lock timeout header 224 signifies the creation of a new lockaccording to the value of the lock timeout header 224. If the Lock-Tokenheader 222 is included then the lock timeout header 224 signals therefresh of an existing lock. If the lock timeout header 224 is set to 0seconds than an unlock is indicated (in this case, the Lock-Token header222 and a correct token are required to unlock the file). Furthermore, aLock-Token header 222 and token are preferably included in the responseto any write operation on a locked resource. Example request 228 showswhat a typical POST+UNLOCK request might look like. Note the inclusionof a Lock-Token header 222 and a lock timeout header 224.

Referring to the PUT verb combined with a locking operation, note thatthe Lock-token header 222 and correct token are needed to modify alocked resource. No token is needed if the resource is not locked. If notoken is included but a lock time is specified, then the natural lockinglogic occurs; a lock is granted if no lock exists, and the PUT and lockare denied if a lock already exists. In sum, if the correct token isincluded with a PUT request the client can perform any PUT operation orany PUT operation combined with a lock operation. A typical PUT+REFRESHrequest is shown by request 230. The lock timeout value of 120 secondsindicates a refresh or resetting of the lifetime of the lock to run foranother 120 seconds, and the lock token is the key that the server usesto authorize both the PUT operation and the REFRESH operation. In apreferred embodiment a Lock-Token header included in a non-writeoperation is ignored; i.e., “GET+verify an existing lock” is notsupported.

FIG. 9 shows a mechanism for compounding property methods with HTTP orWebDAV methods or verbs. These compound methods correspond to themethods 148, 150 in FIG. 5. The compounded property methods use twoindicators; a special content type header value 240 (e.g.,“multipart/MSDAVEXTPrefixEncoded”) and a special extensions header 242with various possible values such as “PROPFIND” and “PROPPATCH”. Thecombinations in table 244 are self-explanatory and the resulting methodsallow a resource to be accessed or modified while at the same timeobtaining or setting one or more properties of the relevant resource.Furthermore, the standard Content-length header will be used and willgive the value of the total message body or payload, which may alsoinclude properties as well resources (discussed further below).

In conformance with the rules of table 244, an example GET+PROPFINDrequest 246 is shown. Note the inclusion of an indication of thePROPFIND portion of the method in the form of the special extensionsheader 242 with the appropriate value or verb.

Although in one embodiment property related methods are compounded ontoother methods using headers and a message body extension, otherapproaches may also be used. For example, the WebDAV PROPFIND andPROPPATCH methods could be overloaded using new headers. Furthermore,there are different ways for combining a resource and a set ofproperties in a message body. All of the properties can be put inseparate headers, since most property sets are of manageable size. Theproperties could be assigned to respective different headers, althoughthis would require more coding to handle transport of properties. Inanother embodiment, all of the properties (XML structure) can be placedin one large header, however, headers could potentially become largerthan the buffers that some web servers allocate for header handling.

It is possible that some implementations may need to simultaneously setproperties (PROPATCH) and get properties (PROPFIND) of a resource. Forexample, to determine whether a particular property was properly set, orto determine what a property was set to before it was changed with aPROPPATCH. In this case, “PROPPATCH” and “PROPFIND” can both beincluded, and a convention can be established for the location of sentand returned properties in the message body.

Although the WebDAV protocol does not specify particular properties forresources, some typical properties are analogous to properties ofobjects in a file system, for example content size, creation date, dateof last modification, last modifying user, special folder type, resourcetag, file attributes, creation time, last access time, last modifiedtime, and so on.

FIG. 9 also shows an example GET+PROPFIND response 250. Note that thecontent type header field 240 signals the presence of a multi-partmessage body using the special “multipart/MSDAVEXTPrefixEncodedheader”extension. The lock related information is not required for thePUT+PROPPATCH method but may signify the presence of a server-side lock.The content type header field 240 signifies the presence of themulti-part message body 248 within a message body 64. Generally thosemultiple parts are divided by a length field followed by a correspondingdata, in other words, the message body 64 carries one or more pieces ofdiscrete data, each preceded by a corresponding length indicator. Thesizes of the length fields and the sizes of their data add up to thestandard Content-length header. The example response 250 in FIG. 9happens to have a properties section and a resource section, eachpreceded by a respective length field, for example, a 64 bit integer.Because compound authoring is designed as an HTTP extension, thestandard HTTP message body 64 is used. Because properties may need to beexchanged in a message that may also include a resource such as an HTMLdocument, the length-data pairings allow both properties and resourcesto be carried in a same message body 64. The standard Content-lengthheader gives the total length of the message body 64/248 and can beused, in conjunction with the length indicators, to parse out thesubstantive pieces of content in the message body 248.

Referring back to the methods 152, 154 in FIG. 5(POST|GET+PROPFIND+LOCK|REFRESH|UNLOCK,PUT+PROPPATCH+LOCK|REFRESH|UNLOCK), these methods can be implemented bycombining the properties and locking extensions discussed above. Becauselocking functionality and properties functionality is logicallyseparate, the methods and headers discussed above can readily coexist ina message. FIG. 10 shows further compounded methods. The top message isan example of a PUT+PROPPATCH+UNLOCK request 270. Note the size of thebody, including the size of the length fields, is 114234. The bottommessage is an example of a corresponding response 272. A response thatis successful need not differ from the response to a normal PUT request.The lack of a lock token header denotes a successful unlock. FIG. 11shows an example POST+PROPFIND+LOCK method request 290 and acorresponding response 292. The request 290 causes the server to put aresource or file, set some properties, and unlock the file or resource.

FIG. 12 shows an error handling table and examples of a response 302using extended error handling. A number of types of errors can occurwhen creating a resource on a server via an extended HTTP authoringrequest, for example, insufficient permissions, a resource checked outby another user or not checked at all, a quota violation, or a blockedfilename or file type, the presence of a virus, etc. Other errors suchas a missing property can occur when attempting to write to a file orresource. When an authoring error occurs on a server, typically theserver may have rich system-level information about the error.Previously, when a module or server that implements WebDAV methods wouldencounters an error it would translate that error to a standard HTTPerror code. A client might attempt to provide a useful message about theerror code, perhaps using a corresponding hardcoded message string.However, the standard HTTP error codes are not rich enough to supportthe number and types of errors which users can encounter using extendedHTTP authoring. Therefore, an extension is optionally provided to extendthe error information fed back to a client, while keeping the existingHTTP error code, which allows for backward compatibility. This extendederror handling is accomplished by including in responses informationspecific to system-level errors on the server.

As seen in FIG. 12, extended error handling can be realized using a newHTTP header, for instance “X-MSDAVEXT_ERROR: Decimal; String”. Thedecimal portion is a code that maps to a system-level error such as aUnix file control error or a Win32 error. Preferably, the String portionis in UTF-8 format.

Regarding compounding extensions of web authoring protocols in general,it should be noted that some proxy servers may attempt to interpretrequests and send back cached responses. Therefore, it is preferablethat clients only use the new extensions or methods with POST ratherthan GET. Furthermore, when responding to a concatenated method or verbas discussed above, a server should mark a response to indicate that itshould not be cached, using, for example, a header like “cache-control:private”.

The server and client processes for using extended compound authoringmethods are fairly straight forward given conventions as discussedabove. Publicly available source code and documentation can be consultedto determine how to implement servers and clients with the functionalityfor performing atomic authoring methods and in particular locking andproperty functionality. This functionality can be performed in serialfashion when a compound method is encountered. For example, whereaspreviously a server may have had a function to handle a LOCK method anda function to handle a POST method, roughly, those functions can beinvoked consecutively when a compounded POST+LOCK method is received.

Although HTTP and WebDAV have been discussed above, the ideas discussedabove are expected to be applicable to any future variations or versionsof HTTP and WebDAV. Furthermore, a standard protocol is considered torefer to any future or current standard protocol.

In conclusion, those skilled in the art will realize that storagedevices utilized to store program instructions can be distributed acrossa network. For example a remote computer may store an example of theprocess described as software. A local or terminal computer may accessthe remote computer and download a part or all of the software to runthe program. Alternatively the local computer may download pieces of thesoftware as needed, or distributively process by executing some softwareinstructions at the local terminal and some at the remote computer (orcomputer network). Those skilled in the art will also realize that byutilizing conventional techniques known to those skilled in the art, allor a portion of the software instructions may be carried out by adedicated circuit, such as a DSP, programmable logic array, or the like.

All of the embodiments and features discussed above can be realized inthe form of information stored in volatile or non-volatile computer ordevice readable medium. This is deemed to include at least media such asCD-ROM, magnetic media, flash ROM, etc., storing machine executableinstructions, or source code, or any other information that can be usedto enable a computing device to perform the various embodiments. This isalso deemed to include at least volatile memory such as RAM storinginformation such as CPU instructions during execution of a programcarrying out an embodiment.

1. Volatile or non-volatile machine-readable media storing informationto enable a device to perform a process for servicing requests fromclients, the process comprising: handling standard HTTP get requests,standard HTTP post requests, and standard HTTP options requests andsending responses to corresponding clients; handling HTTP standard ornon-standard authoring requests that direct the device to lock/unlockresources or direct the device to obtain or set properties of resources;and when errors occur handling the HTTP authoring requests, returningresponses comprising error information that is not a HTTP status code.2. Media according to claim 1, where the error information correspondsto a system error of the device that caused the errors to occur. 3.Media according to claim 1, where the error information comprises anextended error header name and an accompanying header field comprisinginformation identifying and/or describing a corresponding error. 4.Media according to claim 3, wherein the header field comprises a systemerror code of the device.
 5. Media according to claim 3, wherein theheader field comprises a string specifically describing the error. 6.Media according to claim 3, wherein the header field comprises a systemerror code of the device, the error code comprising or identifying asystem error of the device.
 7. Media according to claim 3, wherein thesystem error comprises a file locking error, or a file or directory readerror, or a file or directory write error.
 8. Volatile or non-volatilemedium for storing digital data, the medium storing an HTTP response,the HTTP response comprising: a standard HTTP status code header andcorresponding HTTP error code; and an indication of a server-side error,where the indication is not defined by a standard HTTP.
 9. Mediumaccording to claim 8, wherein the indication comprises an HTTP headerfield specifically defined for conveying extended error informationother than standard HTTP error codes.
 10. Medium according to claim 9,wherein the header field comprises a field name not defined by astandard HTTP protocol and a field body that carries extended errorinformation about the server-side error.
 11. Medium according to claim10, wherein the field body identifies a particular type of server-sideerror and that error does not correspond to a standard HTTP error code.12. Medium according to claim 10, wherein the field body comprises anoperating system error code or a string describing an operating systemerror.
 13. Medium according to claim 12, wherein the server-side errorcomprises an operating system locking error, or an error reading orwriting a server file or server directory.
 14. Volatile or non-volatilestorage for use with a processing device and storing information forenabling the processing device to perform a process, the processcomprising: generating an HTTP request and sending the HTTP request to aserver; receiving from the server an HTTP response to the HTTP request;and parsing the HTTP response for a non-standard extended error headerand extracting from the non-standard extended error header informationabout an error on the server.
 15. A storage according to claim 14,wherein the HTTP request further comprises a standard HTTP status codeheader and corresponding error number.
 16. A storage according to claim15, wherein the information about the error on the system comprisesdetail about a specific type of file system or operating system error onthe server.
 17. A storage according to claim 14, wherein the informationabout the error on the server comprises an operating system errornumber.
 18. A storage according to claim 14, wherein the informationabout the error on the server comprises a string describing an operatingsystem error.
 19. A storage according to claim 14, wherein theinformation about the error on the server identifies or describes aspecific system-level error of the server.
 20. A storage according toclaim 14, wherein the HTTP requests comprises an HTTP-based authoringrequest, either compounded or non-compounded, and the error on theserver was an error performing a locking-related or properties-relatedmethod.